Identity > Application Access

Application Access

Identity

475 sections

6432 source tickets

Last synthesized: 2026-02-13 00:55 | Model: gpt-5-mini

1. Okta SSO: 'user is not assigned to this application' blocking app access

95% confidence

Problem Pattern

Users were prevented from accessing vendor applications or received incorrect roles when IdP→application assignments, group membership, dynamic-group rules, SCIM provisioning, or asserted profile attributes did not match vendor mappings or when vendor-side account state blocked provisioning. Symptoms included Okta errors such as “The user is not assigned to this application”, OAuth/OIDC client-assignment failures (for example AADSTS50105), SAML/OIDC assertion failures or login loops, missing Okta Dashboard tiles, vendor access-denied screens or unexpected password prompts, provisioning/import errors (for example operationNotAllowedForUser or userNotFoundOrNotVisible), and dynamic groups failing to evaluate when required source attributes were absent. Common triggers included missing app or license-group membership, misconfigured HR or dynamic-group filters, absent HR-source attributes, delayed or failed Okta→vendor syncs, deactivated/duplicate/renamed accounts, username/email transformations, SCIM/API/token failures, and client-side caching or propagation delays.

Solution

Incidents were resolved by restoring the IdP→application assignments and ensuring vendors received the identity, group, license, and attribute data their mappings required. Observed resolutions included:

• Restored Okta application assignments and added users to entitlement/license groups; Okta Dashboard tiles and SSO sign-ins returned once membership propagated (propagation ranged from minutes to ~24–48+ hours; some native clients cached state longer).

• Assigned or re-assigned applications, created dedicated Okta groups for access when HR-based provisioning was impractical, and supported manual additions where necessary.

• Used self-service provisioning flows when administrators could not directly grant access; in at least one case users were instructed to create their own account via the self-service provisioning portal so vendor-side provisioning completed and access was reinstated.

• Reworked HR-source provisioning filters and dynamic-group rules, re-synced sources, escalated directory-sync issues, and where HR lacked separating attributes created explicit exclusion lists or mail-enabled security groups in Azure AD and automated membership enforcement.

• Addressed missing source attributes that prevented dynamic-group evaluation (for example absent employeeNumber) by temporarily adding users to groups while upstream attribute sourcing was planned.

• Corrected Okta profile attributes and added required SAML/OIDC assertion attributes; completed SAML integrations by exchanging IdP/SP metadata and X.509 certificates when assertions had failed.

• Reconciled username/email conflicts, duplicate or pre-existing vendor accounts, and external-account linking by remapping Okta usernames to vendor identifiers, creating provisioning aliases/proxies, or linking existing vendor accounts to Okta-managed identities; signing in once after Okta assignment often completed vendor provisioning or approval flows.

• Resolved vendor-side local account blocks by completing vendor password-reset or account-activation flows so Okta auto-login could complete.

• Fixed SCIM/API provisioning and bulk-import failures by rotating/verifying SCIM tokens, performing manual imports/syncs, or adjusting import mappings when vendor username transformations prevented account matching; some import errors referencing operationNotAllowedForUser or userNotFoundOrNotVisible were traced to deactivated or not-visible Okta records and were resolved by restoring visibility/reactivating accounts and re-running imports.

• Reactivated upstream HR or directory records when they were the source of downstream SSO failures and performed Okta account-level administrative resets when a blocked Okta account state affected multiple applications.

• Resolved native/desktop client SSO issues by reinstalling native SSO clients or signing in via the organization’s custom Okta domain; some vendor installers required tenant/install permission fixes or creating apps from vendor SAML metadata to clear installer 'Forbidden' errors.

• Addressed browser/client caching and cookie/session problems by launching the vendor app from the Okta Dashboard tile, clearing browser cache and cookies, using private/incognito browsing, or switching browsers; these steps resolved many tile-launch and SSO session errors.

• Mitigated vendor web UI failures (for example a blank page after successful SSO) by restoring Okta assignment and, when the web client remained non-functional, using the vendor’s installed app or embedding the vendor in Teams as a practical workaround until vendor-side fixes were applied.

Source Tickets (701)

2. Missing product licenses, approvals or invitations preventing access

95% confidence

Problem Pattern

Authenticated users, guests or service accounts were unable to access or install specific SaaS applications, workspace/team pages, project boards, calendars or paid features after SSO, invitation or provisioning flows. Symptoms included explicit 4xx/403 'not assigned' errors, tenant/OAuth consent blocks, undelivered/expired/invalid activation or invitation links, vendor trial-disabled redirects, misleading 'license expired' dialogs, silent sign-in failures, and Intune/Company Portal installation or activation failures. Failures often affected only some services (for example email or core portals remained accessible while Teams, Jira or Confluence were blocked) and commonly followed missing or incorrect product licenses/SKUs, seat exhaustion, provisioning/SCIM or group-membership delays, Conditional Access/device-compliance blocks, DNS/domain connector problems, or vendor license-server outages.

Solution

Access incidents were resolved by restoring consistent entitlement, invitation and provisioning state across the identity provider/directory and vendor systems and by coordinating among IdP administrators, licence owners/cost centres, approvers/workspace owners, application owners and vendor support. Observed remediations and outcomes included:

• License and SKU fixes: administrators reassigned or restored SKUs and seats, reclaimed or reallocated expired seats, and resolved seat‑type or bundled‑entitlement conflicts; assigning the correct vendor entitlement often restored access within minutes (for example upgrading a Microsoft licence from A1 to A5 restored Office functionality and resolved downstream SSO/access failures).

• Directory / enterprise-app assignments and Intune installs: missing Azure AD/enterprise‑app assignments were corrected when users could not install vendor apps via Company Portal/Intune; applying the proper directory/app assignment or licence restored installation and sign‑in, while persistent device‑side Company Portal failures required targeted device remediation or replacement.

• MFA and authentication‑factor remediation: cases that depended on fresh authentication factors were resolved by guided MFA re‑enrolment and by sending manual setup or recovery links.

• Provisioning, invitations and delivery: stale pending invites were cleared and activation emails reissued; SCIM/provisioning records and group memberships were corrected. Small IdP/group changes typically propagated in minutes, while larger directory/vendor syncs took hours to days.

• Temporary entitlements and operational workarounds: temporary seats or trial pools were provisioned while procurement completed; owner‑driven invites, delegated/admin roles and reference accounts provided interim access paths. In several incidents credentials or notifications were delivered to an alternate/private email address to restore access while entitlement issues were resolved.

• Vendor outages and vendor interventions: vendor service restorations resolved mass activation failures and misleading 'license expired' dialogs; vendors cleared delivery suppressions, enabled accounts pending approver action, issued direct activation links or granted specialist approvals when required.

• Device compliance and Conditional Access: failures tied to unmanaged or non‑enrolled devices were cleared by restoring device‑enrolment/compliance state or by using managed workstations, and by resolving group membership so Conditional Access policies allowed product sign‑ins.

• Account/authentication mismatches and admin consent: duplicate or personal accounts were reconciled by mapping the correct IdP identity to the vendor account and assigning the correct vendor licence to that identity; tenant admin‑consent blocks were removed after security/data‑protection reviews or were documented when consent was explicitly denied.

• Domain, DNS and integration fixes: branded short links and custom subdomains were fixed by connecting organisation domains and DNS records in vendor portals; API scopes, credential types and provider configurations were corrected and vendor accounts were re‑created when necessary to restore automation and API access.

Remediations consistently required tracking until directory and vendor systems fully propagated the corrected entitlement, invitation or provisioning state; the most common final step was ensuring the vendor licence (correct SKU/tier), workspace approval and the IdP‑authenticated account all matched for the user.

Source Tickets (1325)

3. Care / Care Stage: account creation, permissions and environment access issues

95% confidence

Problem Pattern

Users and service accounts were unable to access applications or perform expected in‑app actions because downstream accounts, entitlements, licenses, application assignments, or in‑app roles were missing, inactive, duplicated, blocked, or mis‑mapped. Symptoms included SSO failures (for example rejected authenticator codes or “no active <app> account”), missing or unassignable apps in IdP dashboards, pending or stuck access requests (including approvals that were granted but not implemented), empty/incomplete UI tabs, undelivered activation/reset emails, and HTTP 403 permission‑denied responses. Frequent triggers included connector/SCIM failures, tenant/endpoint mismatches and replication delays, stale IdP attributes or group‑to‑role mappings (including dynamic groups), missing HR identifiers (for example Workday IDs), incomplete or misrouted approval workflows (for example approvers unaware of required actions or absence of a reference user for permission packaging), unsupported bulk onboarding, role/entitlement conflicts from dual‑role accounts, and SSO‑only integrations that returned no user attributes. Many incidents affected applications that relied on HR/product‑managed identifiers or intentionally restricted groups, causing assignment to be blocked even when users held another valid role.

Solution

Access incidents were resolved by reconciling authoritative identity records, restoring or creating downstream accounts and entitlements, completing and validating approval workflows, repairing provisioning integrations, and reassigning applications in the IdP so users and service accounts regained expected capabilities. Key resolution actions included:

• Corrected IdP attributes and AD/Okta group memberships and repaired group‑to‑role mappings; affected accounts were moved into equivalent groups or attribute/claim sets and duplicate downstream profiles were merged or removed so SSO logins and in‑app role mappings succeeded. Identifier mappings (for example email↔username) were supplied when onboarding used different identifiers.

• Reactivated, reprovisioned, or created downstream user and service accounts (including supported bulk/team onboarding) and recorded higher/restricted reference roles that required manager or application‑owner approval so cloned accounts preserved expected configurations while respecting approval constraints.

• Clarified and completed pending approvals and approver responsibilities: where line managers or approvers were unaware of the required steps, support either performed the permission change on the owner’s behalf or provided the approver with a reference user/permission package and explicit implementation notes; approved but unimplemented requests were re‑opened or re‑created when necessary so changes were applied.

• Identified or created reference users and permission templates and cloned in‑app roles from reference users when administrators needed equivalent configurations and a baseline was not supplied.

• Re‑enabled or directly assigned missing applications in the IdP/Okta dashboard so apps reappeared for users; several cases were resolved by restoring application assignments in the user’s Okta dashboard.

• Provisioned or corrected product licenses and installed/enabled required application clients where necessary.

• Restored in‑app permissions, site/course scopes, content visibility and dataset/dashboard sharing by adding appropriate Azure AD/application groups or owner‑scoped grants and by cloning in‑app roles from reference users when administrators needed equivalent configurations.

• Repaired or re‑enabled SCIM/connectors, repointed integrations when tenants/endpoints were incorrect, and allowed for propagation windows where transient replication delays resolved access.

• Created or corrected app registrations/service principals and non‑interactive service accounts, recorded required directory/app‑level permissions, and cloned permissions from reference users so new or repaired accounts received equivalent in‑app roles and API access.

• Addressed client‑side/session caching and invitation issues by retesting sessions (for example in private/incognito mode), reissuing undelivered invites/activation emails, and confirming users did not submit duplicate onboarding requests via Self Service.

• Diagnosed cloud‑provider permission denials caused by IAM policies or explicit denies (for example on assumed role ARNs); affected users were routed through the organisation’s access‑request process and regained access after the account/role/permission was provisioned.

• Routed and coordinated incidents that required HR‑managed identifiers (for example Workday/EmployeeID) or where target users had no upstream account to the owning downstream account or HR/product teams; where owners supported alternatives, alternate identifier mappings or provisioning flows were implemented so downstream accounts could be provisioned.

• Documented and escalated SSO‑only integration cases where no user attributes were returned to the IdP; those incidents were routed to product/owner teams and resolved by enabling attribute/provisioning channels or implementing alternative provisioning flows when available.

• Clarified and resolved entitlement conflicts caused by dual‑role accounts (for example users who were both staff and students): these incidents were identified as intentional downstream restrictions and were resolved by coordinating with the owning product/HR teams to provide the appropriate identifier, adjust account classification, provision a separate profile when supported, or apply an owner‑approved exception or alternate mapping.

• Clarified and resolved incidents caused by renamed or relabeled in‑app menu items and roles: support confirmed label/name changes and coordinated with application owners to map or restore expected role names and apply equivalent permissions.

Incidents that arose from process failures (for example managers instructed to implement permissions but unfamiliar with the process, absence of a reference user, or approvals that were auto‑closed) were resolved by clarifying the responsible party, supplying or creating a reference permission bundle, re‑opening and applying approved requests, and coordinating follow‑up with product owners so approvals resulted in implemented access.

Source Tickets (1258)

4. External / contingent-worker accounts for guest access and collaboration

• Directory group membership: users or devices that lacked the required Active Directory/Azure AD group membership were added to the appropriate directory group so the entitlement appeared in the user’s Self Service view.

• Catalog visibility and minion entries: some long‑term (3‑year) admin entitlements were present in the Self Service catalogue as separate "minion" entries. Support located the minion catalog entry and the user activated it; activation applied the 3‑year admin entitlement and resolved the duration mismatch.

• Management backend rollout / catalog republish: Admin‑Minion/admin‑request catalog items that had not been published or rolled out correctly were re‑released so the catalog item republished; devices then retrieved the updated catalog (Inventory Update via Self Service) and regained visibility of the entitlement.

• Privilege‑elevation provisioning: failed privilege‑elevation or provisioning components were restored or reprovisioned; subsequent elevation attempts completed successfully and credential prompts were accepted.

• Long‑term admin entitlements and approvals: expired or missing config profiles for long‑term admin entitlements were renewed and required manager/CostCenter approvals were obtained; users were added to the long‑term‑admin directory group so long‑term privileges became active.

• UI relocation: in cases where users reported a missing request option, the admin‑request flow had moved within the Self Service interface (for example to the app toolbar/menu); using the relocated flow restored ability to request admin.

• Multifactor authentication blocking elevation: users whose password‑only sign‑ins failed due to MFA were reset and re‑enrolled in MFA; after MFA re‑enrollment they were able to authenticate and complete the Self Service admin elevation.

• Approval workflow / Jira automation: requests that lacked a manager or CostCenter approver were failing to progress and were auto‑closed by Automation for Jira; adding the appropriate approver to the ticket or approval policy allowed the request to be processed.

• Service‑desk form mapping: some tickets showed unrelated Affected Software (for example 1Password) or lacked an "Other" option, which caused confusion in triage; in reported cases locating and activating the correct catalog/minion entry resolved the entitlement issue.

After the applicable corrective actions above (group membership fixes, locating/activating minion catalog entries or republishing the catalog and refreshing inventory, reprovisioning elevation components, renewing config profiles and approvals, UI relocation, MFA re‑enrollment, or fixing approver assignments) affected users regained the ability to request admin access and complete installations or updates.

Source Tickets (13)

7. Azure Portal VM visibility missing due to VM access group membership

90% confidence

Problem Pattern

Users were unable to see or manage team virtual machines and other Azure resources in the Azure Portal due to missing or incorrect Azure AD group membership. Newly provisioned Windows 11 devices failed Microsoft 365 sign‑in. Individual VMs were unreachable at the host level (SSH or admin sign‑in), sometimes due to stale or unauthorized SSH keys. Windows notebooks also experienced loss of general internet connectivity when establishing Azure VPN connections while attempting to reach VMs. Affected systems included Azure Portal, Azure AD, Azure VPN, Azure VMs, SSH, Microsoft 365, Windows device enrollment, and endpoint protection tooling.

Solution

Access and management-plane visibility were restored by adding affected users, service accounts, or devices to the appropriate Azure AD groups (examples: UIPath VM access group, IUG‑Sec‑Azure‑SynteaB2B, and Windows “Win11” device groups). After Azure AD group membership propagation (typically ~1 hour) the team’s resources became visible in the Azure Portal and users acquired the group-associated permissions, including the ability to create resources and to sign in to Microsoft 365 from new Windows 11 machines. For cases where portal or RBAC changes did not immediately allow host access, VPN access was provisioned for users and VPN connection details were delivered so they could reach VMs for SSH or maintenance. Host-level remediation included granting administrative access on the VM, removing obsolete or unauthorized keys from the VM’s authorized_keys, and onboarding the VM to Microsoft Defender. Stakeholders were notified and access restoration was confirmed.

Source Tickets (8)

8. Microsoft Dataverse table ownership and Dynamics security-role mapping blocking Power App access

68% confidence

Problem Pattern

Authenticated users, guest accounts, service principals, or application users sometimes authenticated successfully but were denied Power Apps access or returned incomplete Dataverse data. Reported symptoms included the Power Apps UI message “You can't open apps in this environment. You are not a member of the environment's security group.”, an “Access request. Let us obtain permission to use this app” dialog with pending/unapproved requests, AppForbidden/HTTP 403/metadata access‑denied responses, client_credentials token failures, connector/metadata enumeration failures, record payloads with missing/null attributes, and Power Automate flows failing to run. Triggers included missing or disabled Dataverse systemuser records, lack of environment membership or app sharing, misapplied Dataverse security‑role mappings (including absence of base roles such as Basic User), missing application users or client credentials, missing Power Apps licensing, and failures in service‑desk/service‑portal approval paths when support systems used different SSO or separate accounts (for example Atlassian accounts not linked to institutional Okta or lacking 2FA).

Solution

Access and visibility incidents were resolved by ensuring callers (users, guest/external accounts, service principals, and application users) had an active Dataverse systemuser record, valid credentials, required privileges, and any needed Power Apps licensing. Specific remediations that were observed to resolve incidents included:

• Restored environment/app access by approving pending Power Apps access requests or directly sharing the app and/or adding the user or Azure/Entra AD group to the Power Platform environment’s security group. In several cases access requests remained unapproved until an environment or tenant admin approved them in the Power Platform admin center or app owner shared the app explicitly.

• Ensured role mappings granted effective table access by assigning required base system roles (for example Basic/Basic User) in addition to table‑specific roles so Azure/Entra AD security groups conferred privileges as expected. Custom security roles were created by copying Basic/Basic User and adding explicit Power Automate/flow execution permissions when approvers could not run production flows or long‑running actions timed out.

• Restored missing or disabled accounts and syncs by re‑enabling or recreating guest/external accounts, provisioning and assigning required Power Apps licenses (for example Power Apps Premium for model‑driven apps), and forcing or verifying Azure AD ↔ environment sync so enabled systemuser records were present after sync.

• Represented Azure AD app registrations as Dataverse application users, restored valid client credentials or recreated missing client secrets, and granted those application users the specific Dataverse security roles/privileges required (including environment‑admin/systemadministrator equivalents when appropriate). Application users were granted explicit metadata read privilege when GlobalOptionSetDefinitions GETs returned HTTP 403.

• Changed Dataverse table ownership from User to Organization where organization‑level visibility was required, and reviewed field/column‑level security and field security profiles when APIs returned null attributes.

17. Cost-center approver/owner entries in Workday causing incorrect tool access-request routing

• Usable shared credentials existed: requesters supplied the credentials via ticket, IT booked the subscription or plan, and IT completed provisioning for the shared/course account.

• No shared credentials and the service was person‑bound or tied to the org identity provider: support informed requesters that no IT‑maintained shared account was available and advised self‑registration or requesting an individual license via the Application Self Service.

• Account created/stored by local Procurement or site staff: support advised checking the site 1Password Standort_Vault for stored access and confirming required budget assignment before provisioning.

• Vendor or identity changes disabled password‑based shared access (SSO enforced): the organization procured separate individual licenses or treated credential transfer as impractical. For departing owners, support cancelled the existing account and created a new account for the replacement rather than transferring credentials.

Additional observed nuance from Calendly: an invitation sent to a credentialless/functional shared mailbox produced a password prompt that could not be completed because the mailbox had no password, but the invitation email enabled a named user to accept and manage the service by signing in via Okta SSO with their own account when the vendor supported that flow. Support therefore noted that some vendors (for example, Calendly) were effectively incompatible with passwordless functional/shared mailboxes for direct mailbox sign‑in, but invitations landing in those mailboxes could sometimes be accepted by a human who authenticated with org SSO.

Where IT did not manage vendor budgets or accounts (for example, Lieferando), support declined to provide access and advised using a personal account and submitting an expense claim via Workday. Each ticket recorded whether shared credentials existed, whether vendor supported team/shared seats, whether SSO mapping blocked non‑owner logins, whether Procurement owned or stored credentials, and whether a budget needed to be assigned; the chosen resolution reflected those constraints.

Source Tickets (10)

23. Internal service portal and sandbox access provisioning and agent role activation

95% confidence

Problem Pattern

Users were unable to access internal service portals, non-production environments (sandbox/UAT/stage/test), corporate software catalogs, or ticketing boards. Symptoms included missing or hidden Okta app assignments or tiles (production visible while dev/stage missing), non‑selectable options or failed forwarding/submit actions on access‑request forms, authentication failures after credential or account changes, and absent Jira Service Management agent/admin roles preventing ticket-board actions. Some users had production access but lacked environment-specific authorization in non-production instances (for example Care Stage). Affected systems included Okta-integrated apps, CARE/myCampus, EPOS/Hyperion links, Jira Service Management/Service Desk, and Salesforce UAT.

Support cleared stalled approval requests using approaches tailored to the cause. When the app or sandbox was missing from the company software catalogue, requesters were directed to the owning team’s service portal or support logged a new software/sandbox request that documented required users and integration/feature requirements (for example Workday integration, mobile barcode scanning). Administrators sometimes enabled/whitelisted and published the application or sandbox to the company portal; published entries typically appeared in the portal within about 30 minutes. When approvals were delayed by incorrect or unresponsive approvers, support reopened or rerouted approvals by updating the approver in Automation for Jira; in some cases designated approvers completed approval directly in the SaaS which finished provisioning. Where automated approval routes failed or requests had timed out, support performed manual provisioning actions to complete access: adding users to the company‑managed account in the SaaS, adding the app to users’ Okta dashboards/assignments, re‑enabling accounts, or sending direct invites/emails. Support observed that some Automation for Jira requests auto-declined after the 14‑day approval window and could not be reopened, and that some tickets routed to specialist teams were closed as 'Won't Do' or otherwise declined without provisioning; resolution-label mismatches were noted when an approver had granted access but the ticket was still marked 'Won't Do'. For software using form‑based license mapping, selecting the correct license variant (for example 'Miro (Free Restricted)') resulted in automatic license assignment once the form was approved. Tickets sometimes contained a 'request timeout' comment even when a later approval or correct form selection caused provisioning; when Okta already showed an assignment, support verified the assignment, informed the requester that the application was available, and closed the ticket.

28. Access provisioning for internal transfers blocked by incorrect cost‑center selection and per‑app request requirements

86% confidence

Problem Pattern

After internal transfers, role changes or new hires, users reported missing or incomplete application access, group memberships, telephony extensions or shared mailboxes. Symptoms included provisioning stalled by pending or mis‑assigned approvals, absence of accounts or group assignments from Workday sync, expired activation links, and missing application‑level permissions without explicit error messages. Telephony provisioning errors sometimes presented as blocked Salesforce telephony entries when the external telephony account (eg. Vonage) was deactivated. Affected systems included Workday‑synced flows, Okta‑provisioned apps, telephony platforms (Vonage, Cloudya/Nfon), Exchange/Office365 mailboxes, and internal permissioned apps (Salesforce, Teams, Miro, BIC, EPOS).

Solution

Support verified the user’s new department/cost‑center and new position with the previous team lead and checked Workday status before applying identity or group changes; provisioning that depended on Workday or cost‑center data was held until the HR record, approvals and job description were present. Users were informed when particular tools required separate self‑service requests (for example Miro and BIC). When access requests were blocked by incorrect approver assignment, the approver was changed to the manager so the request could complete. For urgent onboarding where HR data or cost‑center was not yet available, specialists temporarily provisioned access by directly assigning the application in Okta and recorded authorized exceptions in the approval workflow (Jira). Role‑aligned permissions were set by mirroring a comparable reference user’s rights when available, and application‑level permissions were adjusted for systems that maintain internal permission models (for example EPOS and Salesforce role scopes). Telephony issues were investigated for account‑state problems: a deactivated Vonage account was identified as the cause when Salesforce refused to register/update the telephony entry; telephony tasks were resolved by reactivating or recreating the telephony record/extension, assigning external numbers, re‑issuing activation emails or performing password resets as required, and confirming provisioning in the telephony system. Shared mailbox access was granted through Exchange/Office365 mailbox permissions. Tickets were closed after the correct cost‑center and Workday status or required confirmations were present and the requested application, mailbox or telephony access had been provisioned.

Source Tickets (11)

29. On‑prem application inaccessible due to unresponsive host blocking data access

90% confidence

Problem Pattern

User was unable to open the E-test admin application and received an error when attempting to launch it. The user needed to remove scanned documents from the application and move them to a network shared drive but could not access the system or the files. The symptom indicated the e-test host/server was unresponsive and preventing any application-level file operations.

Solution

Solution

Incidents were resolved by addressing one of several account-level or integration-level issues that blocked Okta-to-Workday SSO/provisioning. Support first confirmed the Workday tile identity (users provided screenshots and support verified the tile’s three-dot menu/email shown). Resolutions observed in tickets included: correcting the email address shown on the Workday app tile in the user’s Okta dashboard, re-enabling/reactivating Okta’s Automatic Push (Okta-to-Workday provisioning) so the Workday account could be provisioned/paired, and performing a repair to the Okta–Workday configuration/integration when simple fixes did not restore access. After these changes users regained access (one record noted both Workday and Egencia access were restored). Records also noted account confusion from multiple IU identities and occasional 'PW Reset' flags; some earlier instances recorded causes but no remediation in the ticket notes.

Source Tickets (4)

33. Monday.com board-level edit access blocked despite valid licenses

87% confidence

Problem Pattern

Users with valid SSO and application licenses were unexpectedly limited to viewer-only or could not create or edit resources in collaboration apps such as monday.com, Figma, Miro, and Lucidchart. Symptoms included missing UI options (for example Dev Mode or create-board buttons), explicit in-app messages like “Request permission to create a board” or “Your organization uses Single Sign-On with Miro. Please contact the account admin…”, inability to select or create boards/areas/diagrams even after re-login, and membership or ownership remaining tied to departed users. In some cases identity-provider changes (Okta assignment, unlock, or license grant) did not take effect immediately and took several minutes to propagate; Miro’s in-app Join Request flow sometimes failed to grant immediate membership.

Solution

Support verified application account status and license entitlements and observed that the root cause determined the remediation. Where Okta assignment, provisioning, or account lockout prevented access, assigning users to the application or its provisioning/access group, enabling/unlocking the Okta account, and granting the application license via the Okta Dashboard restored viewer/edit/create capabilities; administrators reported that Okta changes sometimes required about 5–10 minutes to propagate. Pending in-app approval workflows (for example Automation for Jira approvals or Lucidchart request approvals) were completed and restored edit rights. For Figma, assigning users to the correct access group (for example IU-ZZ-OK-ASS-Figma) and enabling account feature toggles (for example Dev Mode) restored space edit permissions and UI options. For Miro, team-level permissions and board/Area ownership occasionally prevented board creation; Miro admins restored functionality by changing board/Area ownership, promoting co-owners, or recovering service-account credentials and admin-console links. Support observed that Miro’s in-app Join Request flow sometimes failed to add membership immediately and that affected users sometimes created resources in other teams as a workaround. Support clarified that IT managed licensing and SSO provisioning while resource-level permissions and ownership were controlled by board/space owners or product admins; when licensing and SSO assignment appeared correct but users still lacked rights, escalations to resource owners or business specialists resulted in ownership or membership changes that restored edit access.

34. Atlassian sign-in failure due to username/character mismatch resolved via Okta SSO dashboard

91% confidence

Problem Pattern

Users were unable to sign in to cloud services (commonly Atlassian, Salesforce, Workday) after SSO redirects to Okta, experiencing repeated "invalid credentials" or "credentials are incorrect" prompts, persistent Okta password requests, or silent sign-in failures that blocked access to billing/support portals and intranet links. Failures sometimes occurred despite Okta logs showing successful SSO and accounts present in the target application; the same credentials were occasionally accepted on mobile. Triggers included username/character mismatches (for example umlauts), username/email renames, new Windows 11 device password acceptance issues, and active mailbox/session persistence. Affected flows required institutional credentials and MFA and typically redirected users to Okta for authentication.

Solution

Access was restored most often by completing the Okta SSO flow from the Okta app launcher/portal, which used the updated Okta identity and allowed immediate access even when browsers or PCs displayed incorrect-password prompts. Backend logs in multiple incidents showed Okta SSO flows succeeding and user accounts present in the target application while end-user browsers reported credential errors; in several cases the same credentials worked from mobile or via Okta. In rename/email-change cases the Okta automation had updated the account but browser sessions still used the old identity; launching the application from the Okta portal used the updated username and resolved the sign-in. Where the target application (notably Atlassian) rejected passwords, administrators reset the application account password and users completed the emailed reset link; some resets did not take effect until the user signed out of an active IU mailbox/session. In incidents caused by broken integrations or malformed SSO configurations, re-establishing or reconfiguring the Okta–application integration restored normal SSO behavior and access to saved intranet links and billing/support portals.

Source Tickets (16)

35. Corporate ChatGPT access blocked by approval workflow and pending invitation acceptance

95% confidence

Problem Pattern

Corporate ChatGPT/OpenAI accounts and higher‑tier entitlements frequently remained in 'Pending' or 'Limited Access' states. Affected users reported 'Limited Access' banners, upgrade/payment prompts, inability to start chats or access platform.openai.com/playground, missing organization/team entries in the account selector, or the UI showing a 'Free' plan. Invitations or approval links were often invalid, expired, undelivered, auto‑closed, or accepted while signed into a different/personal Microsoft account or browser session, which prevented group membership and token issuance. Approval requests also stalled awaiting cost‑center or C‑level approvers, or were auto‑declined by automation rules.

Solution

Access was restored when both a valid OpenAI/ChatGPT invitation was accepted by the intended identity and the organization’s approval/provisioning workflow completed. Common resolved causes and observed fixes included:

• Invitation and identity association: Reissuing invitations or sign‑in links, checking spam and shared inboxes, and confirming receipt/acceptance of a valid invitation consistently correlated with activation. Several cases specifically showed that accepting an invite while signed into a different or personal Microsoft account/browser session prevented the user from being added to the organization/group and from receiving tokens; administrators reissued invitations and users accepted them while logged into the correct Microsoft account, which restored group membership and Playground/tokens access.

• Approval workflow behavior: Provisioning remained pending until catalog/IT approval (including cost‑center or C‑level approvals) completed. Automation rules (for example in Jira) caused requests to auto‑close or auto‑decline when approver fields were unspecified, missing, or inactive (14‑day timeout); some auto‑closed requests could be reopened within a limited window, otherwise a new request referencing the original was created. When an assigned approver could not see approval controls, an alternate approver or administrator completed the approval and a new invitation was issued.

• Product and licensing mapping: Team licenses had been migrated to Enterprise in some provisioning flows; support sent Enterprise invitations after migrations. Higher‑tier entitlements (ChatGPT Team/Enterprise, Pro / GPT‑4) often remained pending until the correct license, cost‑center, or executive approvals were applied.

• Account activation and credential conflicts: OpenAI password‑policy rejections (notably against reused passwords) and conflicts between personal and corporate credentials were documented causes of activation failures; support clarified which account (personal vs. organization) was active and reissued registration flows when needed.

• Provisioning, roles and team features: Administrators manually provisioned users, corrected role or cost‑center assignments, added users to the correct project or organization team (sometimes cloning permissions from an existing user), and enabled team features such as persistent conversation history. Enabling the Playground and chat interfaces restored expected functionality in several cases even when the UI continued to display a 'Free' plan label.

• Cleanup and link/flag fixes: Persistent notifications and error messages were cleared by adjusting invitation and account server/tenant flags. Invalid, expired, or malformed approval or invitation links required reissuing invitations or creating new approval actions to complete provisioning.

In multiple resolved cases the decisive actions were support‑sent invitations accepted by the correct account/identity (including ensuring the correct Microsoft account/browser session) combined with approver action (including cost‑center or C‑level approvals) and any necessary manual provisioning of group/team membership.

Source Tickets (109)

36. Legacy AcademyFive account and username-based login blocking access

90% confidence

Problem Pattern

Users were unable to sign in to AcademyFive/CARE when using email-based credentials or after password resets for legacy accounts that required username-based logins. Symptoms included rejected email sign-in, generic "Sorry!" sign-in messages, and CARE integration failures reporting "Allgemeiner Fehler bei der Verbindung zu CARE" (General error connecting to CARE) on care-admin.iubh.de. Affected systems included AcademyFive, CARE, myCampus and my.iu.org, with users reporting loss of access to attendance and schedule functions.

Solution

Solution

Investigations repeatedly found access failures caused by missing, misaligned, or out‑of‑sync application roles, group memberships, SSO/IdP entitlements, in‑application roles, Teams/application membership, environment-level membership, licensing, or organizational policy constraints. Resolutions observed across incidents included the following:

• Azure AD group and application role membership was reconciled against verified reference users and authoritative lists; disabled accounts and users without required licenses (for example missing Premium Calendar) were removed from groups or moved to appropriate groups, and membership counts were rechecked after propagation. AzureAD PowerShell and Power Automate flows were used for bulk adds and cleanup where appropriate.

• Application content and capability metadata were updated where required to restore functionality and clarity; for one Governance UserFrontEnd case the "Personal Productivity" capability was enabled after licensing and membership were corrected, multilingual informational text and links to the SharePoint article and Governance User app were added, and smart‑links to a PowerApps app and Confluence page were created.

• Third‑party SSO/IdP entitlements (for example Okta) were enabled or corrected; dynamic Azure AD groups were created where IdP syncs lacked stable unique IDs and name‑based dynamic rules were used to populate membership. Identity propagation delays between IdPs, Microsoft Graph and application UIs were observed (typically ~5–10 minutes) and were noted during investigations.

• In‑application roles, Teams/channel/tab memberships and team ownership were restored or corrected via application admin centers or by engaging product/tenant owners when the requester did not know the owning admin. d.velop account issues were resolved by granting write/edit permissions in the application and saving the changes; requesters were notified to test access.

• Service and automation accounts were granted minimal permission sets or moved into the appropriate environment when constrained by environment scoping; flows and connections owned by departed or locked users were migrated to designated service accounts and automation resumed.

• Bulk provisioning and batch enrollment tasks were executed or re-run where appropriate; discrepancies between authoritative lists (dashboards, Skillsmap/Excel, or other sources) and Azure AD group membership were reconciled and counts verified after propagation to confirm success.

• Copilot Studio/agent incidents with greyed‑out Save buttons or persistent agent errors were investigated for environment orchestration permissions, owner/orchestration settings, licensing, and organizational policy limits; ownership changes or licensing adjustments restored functionality where permitted.

Users who successfully authenticated via Azure AD or Okta SSO were unable to access SaaS applications or in‑app content because tenant- or vendor-side entitlements were missing, inactive, pending, or not bound to the SSO identity. Common symptoms included Azure AD AADSTS50105 'application is configured to block unassigned users' errors, missing or invisible SSO application tiles or Company Portal entries, Outlook/Teams add‑in linking failures, looping or failed sign‑in flows, explicit vendor SSO error pages, or a blank dashboard after SSO. Typical triggers included required app assignment or license/seat allocation, pending vendor invitations/approvals, vendor account/profile creation or reactivation, missing in‑app group/role/org/space membership, incorrect org/group bindings, procurement/provisioning sequencing, and directory/SSO propagation delays.

Solution

Access was restored after the missing tenant- or vendor-side entitlement, invitation/approval, license/seat allocation, account/profile creation or reactivation, or in‑app group/role/org/space membership had been completed and directory/SSO changes had propagated. Representative resolutions included:

• Azure/Okta application assignment: granting direct or group assignment in Azure AD Enterprise Applications (or assigning the app in Okta) resolved AADSTS50105 'application is configured to block unassigned users' errors and restored Outlook/Teams add‑in linking and app access. Adobe Creative Cloud access was restored by assigning the appropriate Azure AD group to student accounts.

• Vendor-side group/role membership: adding users to vendor-managed groups or roles inside vendor consoles (for example assigning users to an Adobe Sign product group) restored product access when licensing existed but group membership was missing.

• Vendor invitations and vendor-managed accounts: resending invitations or having vendor administrators create or reactivate vendor accounts and bind licenses to SSO identities restored access (examples included Figma invitations and vendor admin account creation).

• Vendor licensing via internal request systems: granting vendor product licenses directly to vendor-specific accounts through internal provisioning workflows resolved access gaps (example: GitHub Copilot access was granted to a named GitHub account after a DevOps/Atlassian service‑desk request).

• Enabling/configuring vendor SSO: completing or correcting vendor SSO setup removed vendor SSO error pages and allowed normal SSO flows to proceed (example: Agorapulse Okta SSO).

• Approvals and automation: completing pending approver actions or repairing approval routing for application-request workflows removed approval-state blocks.

• Procurement/provisioning sequencing and duplicate records: resolving cases where procurement created license records before vendor accounts, or where provisioning sources produced duplicate order entries, restored expected mappings between identities and licenses.

Timing observations: directory/SSO provisioning typically propagated within ~5–10 minutes though some app visibility or Company Portal entries took longer (one case ~24 hours); an initial SSO login sometimes created a vendor profile before in‑app space/role assignments took effect. Okta-initiated SSO flows sometimes bypassed Azure AD assignment checks while deep links that invoked Azure AD could surface AADSTS50105 blocking. In all incidents users regained access once the missing entitlement, invitation/approval, license/seat allocation, profile creation/reactivation or membership change had been completed and allowed to propagate.

Source Tickets (149)

44. Power BI Self-Service Portal report access blocked by missing Power BI entitlement and owner-controlled report permissions

91% confidence

Problem Pattern

Users could not open Power BI reports or apps: links redirected to a Power BI SignupRedirect URL, a no‑access page was shown, the in‑portal 'Send Request' produced no visible response, or app-specific access failed. Symptoms frequently followed role or organization changes, license/entitlement changes, missing Azure AD or Power BI group/workspace membership, reports owned in owner-controlled workspaces, or deleted report-owner accounts creating orphaned reports. Affected systems included the Power BI service, the Self-Service Portal, Azure AD groups, Microsoft 365 licensing, and the Power BI Admin Portal.

Solution

Solution

Solution

Support identified the owning team or approver and routed permission requests to that owner when central IT lacked direct provisioning rights. Platform specialists performed provisioning for systems they owned; when a platform was not in the software catalog or lacked an Okta/Entra group, specialists either enabled access outside the catalog or assigned platform entitlements directly. When ownership or approver was unclear or cross‑team, requests were routed to DevOps/platform/product specialists or forwarded via the Atlassian service desk to the appropriate owning team. Notable platform resolutions included: • Metabase — platform specialists handled create‑collection and CSV/XLSX export permissions; some dataset export actions required dataset‑owner approval. • dbt Cloud — the Data Platform/DWH team granted evaluation access by assigning dbt Cloud entitlements via the identity provider to a limited set of users. • Sonar/SonarCloud — DevOps processed requests via the DevOps Core Service Desk and granted project access. • Omni — view/read access and platform entitlements were enabled directly when the platform lacked an Okta/Entra group. • SharePoint — restricted access was granted when possible, site‑specific access‑form links were provided when present, and SharePoint site owners were identified for full site or dataset permissions. • TFS — support verified membership and noted when project or board owners had to assign required permissions. • AWS accounts — support determined Infra vs DevOps ownership, forwarded requests to the relevant specialist team, and used Microsoft MyAccess where applicable to grant account access. • Datadog — approvers and approval routing were updated so the platform could grant access. • QuickSight — requests were submitted through the DevOps Portal and account/dashboard access was granted. • MongoDB UI (external users) — prior Company Portal guidance was corrected and the request was routed to the DevOps Core Service Desk and processed through Jira approval automation. • JFrog — identified as a developer tool supported by DevOps and referred to DevOps owners for account provisioning. • vSphere/VMware — access was granted in the vSphere environment by the platform owner/admin and the user was notified. These actions resolved requests where provisioning required platform‑owner intervention or non‑catalog entitlement assignment.

Source Tickets (17)

52. Confluence account creation and basic access provisioning

95% confidence

Problem Pattern

Users reported lack of access to internal Atlassian and analytics applications (Confluence, Jira, Metabase, Index Searcher). Symptoms included failed logins or generic “access denied” messages, missing accounts or missing product licenses/entitlements, inability to open specific Confluence pages or spaces after successful SSO, and requests that referenced Okta entitlements, Workday employee IDs, or email distribution lists for access.

Investigations established whether provisioning failures were caused by product availability (pilot/preview), account eligibility, approval workflow gaps, ambiguous product selection, or training-enrolment restrictions. Actions and outcomes included:

• When a Copilot variant was in an internal test or controlled pilot, affected users were either added to the preview/test user group when preview access was permitted, or informed that access was restricted to a predefined tester cohort; activation from Microsoft was recorded as taking up to 48 hours and some rollouts were run as controlled pilots of roughly two months with very limited licenses.

• SharePoint LMS/training modules for Copilot had explicit enrolment controls: course pages were only active for users who had been pre-registered for the MS Copilot license (the flight‑crew/test group in this case) and the support team recorded that completion of the required course was a prerequisite for using the associated Copilot license. Affected users were informed of the pre-enrolment and course-completion requirement.

• Where provisioning immediately failed or request endpoints returned “Not found,” investigations identified ineligible accounts (for example external accounts or specific organisational assignments), missing works‑council approvals, or other licensing restrictions; affected requestors were informed which restriction applied and why a form might redirect to an organisational page.

• Requestors were informed that personal acceptance of Microsoft’s Copilot terms of use was required, that some organisational contracts did not cover Copilot licenses, and that Copilot must not be used with GDPR‑relevant data.

• Requests that remained in pending/approval‑pending because approvers were absent or the product was unavailable were left in that state while IT communicated pilot windows, changes in availability, and approver coverage via the corporate intranet/SharePoint and Teams.

• Where users submitted ambiguous requests that did not specify which Copilot product they needed, IT clarified the distinction between the Copilot chatbot (copilot.microsoft.com / Bing Chat Enterprise) and Copilot for Microsoft 365 and routed or advised users to the correct request path or form in the Application Self Service / IT Service Portal.

• As interim options when Copilot for M365 licenses were unavailable, requestors were offered accessible alternatives such as the Copilot chatbot and the Guided Conversation Designer, and were advised to monitor the intranet and Teams for pilot progress updates.

Source Tickets (9)

62. Provisioning blocked by vendor license shortage; re-triggered by toggling Okta group membership after license procurement

95% confidence

Problem Pattern

Okta produced an error/notification when assigning a user to an application group because no vendor licenses were available, which prevented the target application from provisioning access. Symptoms included failed group-assignment attempts and lack of final provisioning for the affected application. Affected systems: Okta, NordLayer (VPN) and similar vendor-licensed SaaS.

Solution

Additional vendor licenses were procured and added to the tenant, and provisioning was then retriggered by removing the user from the Okta application group and re-adding them (re-assigning group membership). After the license count increased and the group membership was toggled, the application successfully provisioned access for the user.

Source Tickets (1)

63. SAML/SSO workspace‑booking app access requests (Deskbird) for campus presence

95% confidence

Problem Pattern

Users were unable to access the SAML/SSO‑protected Deskbird workspace/desk‑booking app or book location resources. Reported symptoms included a missing Deskbird tile in the Okta/Azure AD dashboard or self‑service catalog; an error stating “This application is not assigned” / “Anwendung nicht zugewiesen”; provisioning errors such as “not provisioned” or “user not created”; a pre‑auth “Error Checking email” dialog; failed sign‑in at app.deskbird.com; or successful authentication but no booking capability because Workday/Okta group memberships, location/role entitlements, or local resource permissions had not synced. Incidents commonly followed email address changes, onboarding, role/location updates, or vendor‑side account deactivation.

92% confidence

Problem Pattern

Users reported inability to access SaaS or internal applications because their account or presence was missing from the target interface, a required invitation or onboarding state was pending or expired, credentials were unknown or expired, or required roles, permissions, or space/folder membership were not assigned. Symptoms included failed sign-in (including SSO/Okta), explicit 'user not present' or 'user not on interface' messages, missing or expired invitations, insufficient permissions, and inability to enter named spaces or folders. Affected systems included invitation- or role-managed SaaS apps and internal environments (for example OTRS) where explicit reference-user records, account creation, membership, hardware provisioning, or credential dispatch controlled availability.

Source Tickets (1)

Application Access

Table of Contents

1. Okta SSO: 'user is not assigned to this application' blocking app access

Problem Pattern

Solution

2. Missing product licenses, approvals or invitations preventing access

Problem Pattern

Solution

3. Care / Care Stage: account creation, permissions and environment access issues

Problem Pattern

Solution

4. External / contingent-worker accounts for guest access and collaboration

Problem Pattern

Solution

5. Local network/router issues preventing Okta/SSO, VPN and email access

Problem Pattern

Solution

6. Self Service+ visibility for long-term macOS admin access

Problem Pattern

Solution

7. Azure Portal VM visibility missing due to VM access group membership

Problem Pattern

Solution

8. Microsoft Dataverse table ownership and Dynamics security-role mapping blocking Power App access

Problem Pattern

Solution

9. Third‑party meeting notetaker (Fireflies.ai) auto-joining Teams and persistent Enterprise App assignment

Problem Pattern

Solution

10. Managed Identity missing Microsoft Graph appRole permissions blocked Sentinel automation

Problem Pattern

Solution

11. Okta OIDC application registration and client credentials provisioning (redirect URI mismatch)

Problem Pattern

Solution

12. Okta dashboard tile linking to wrong portal

Problem Pattern

Solution

13. Jira board/project admin permissions missing after owner departure blocking edits

Problem Pattern

Solution

14. Azure AD / MS Graph application client secret expiring and requiring renewal

Problem Pattern

Solution

15. Azure AD consent policy gap allowing user-consent to high‑privilege Enterprise Apps

Problem Pattern

Solution

16. PebblePad course content and submission permissions controlled by examination office

Problem Pattern

Solution

17. Cost-center approver/owner entries in Workday causing incorrect tool access-request routing

Problem Pattern

Solution

18. Applicant unable to submit 'Anerkennung von Vorleistungen' online form in Bewerbungsportal

Problem Pattern

Solution

19. SSO access blocked by duplicate/conflicting Atlassian accounts

Problem Pattern

Solution

20. Approval routing stuck due to stale Workday cost-center approver mapping

Problem Pattern

Solution

21. No vendor invitation received after corporate SaaS provisioning request (OpenAI/ChatGPT)

Problem Pattern

Solution

22. Shared SaaS subscription provisioning requiring requester-supplied credentials (Midjourney)

Problem Pattern

Solution

23. Internal service portal and sandbox access provisioning and agent role activation

Problem Pattern

Solution

24. Application license requests via self-service requiring correct approver assignment

Problem Pattern

Solution

25. SaaS access blocked by outdated superadmin ownership or missing superadmin contact

Problem Pattern

Solution

26. Vague report/dashboard access request that had no reproducible access failure

Problem Pattern

Solution